Internet Protocol (IP) packets such as the packet 10 shown in FIG. 1 have been widely used and are well known in the art. IP packets normally include a header 11 and a packet payload 19. In the FIG. 1 example the header 11 includes a source (S) address 12 and a destination (D) address 14. Over time, IP has been enhanced to better suit a communications network where a device, e.g., a mobile node (MN) may change its point of attachment to a network. Various versions of Mobile IP now exist including Mobil IPv4 and Mobile IPv6. These versions of IP include features intended to facilitate mobility.
In the various versions of mobile IP, a mobile node is often associated with a home network where is uses a Home Address (HoA). When visiting a foreign subnet having a different address prefix from the home network, the MN may be assigned a Care of Address (CoA) which has the correct address prefix for the visited foreign subnet. The CoA can be registered with a Home Agent (HA) in the mobile node's home network which is then responsible for forwarding packets intended for the mobile node using the MNs current CoA. The Colocated type of CoA (CCoA) can be used as a source address while in a visited domain for purposes of sending packets. Since the CoA will have an address prefix matching an address prefix associated with the access node in the foreign network to which it is attached, the CoA will pass ingress filtering implemented by the access node in the visited domain. However, using the HoA as the source address, when using standard routing, e.g., in the absence of reverse tunneling or some other method of avoiding ingress filtering based on the HoA, the ingress filtering will normally fail since the address prefix of the HoA will match the prefix of the MN's HA but not the different address prefix of the access router in the visited foreign subnet. This can create several problems including the dropping of packets.
As discussed, as a MN changes its point of network attachment, mobile IP allows it to be assigned a different address, e.g., a Care of Address (CoA), which can be used to direct traffic to the MN while it is attached, e.g., to an access node in a foreign subnet. The foreign subnet Mobile IP for IPv4 addresses this problem by enabling a Mobile node (MN) to use its HoA (Home Address) as a source address on the foreign subnet when forwarding to a Correspondent Node (CN) either directly or via the Home Agent (HA) through the use of reverse tunneling. In this approach, the native forwarding follows the optimal route to the CN but incurs the risk of being discarded by ingress filtering routers due to the topologically incorrect source address. For example, an access router in a foreign network to which an MN is coupled, having a different address prefix than the HA, is likely to discard the packet from the MN having the HoA as a source address since the address prefix will fail to match the address prefix of the router to which it is compared during an ingress filtering step.
To address this problem IPv6 and MIPv6 have therefore constrained the HoA to being used as a source address when either at home or within a reverse tunnel from a foreign subnet via the HA of the MN. The CN then returns packets to the MN HoA, via the HA, and the forward (HA to MN) tunnel based on the CCoA in the HA binding for the MN. In the unicast case, the MN can then activate Route Optimization to bypass the HA in both directions by securely installing a Binding Cache Entry into the CN. The MN then sends from the CCoA source address to the CN directly via a foreign unicast or multicast system, and includes the Home Address Option (HAO) in the unicast packets so that the changing CCoA is masked from the transport layer. The CN sends directly to the MN using a routing header. FIG. 2 is an example of a MIPv6 packet which uses the HAO. In such a case, the header 25 includes a source address 22, a destination address 24, a Next Header (NH) indicator 26 and a Home Address Option field 28. The packet further includes a packet payload 29. The source address 22 is the MN's CCoA while the destination address is the address of the CN to which the packet is directed. The NH 26 is a pointer to the information in the option field 28. The HOA option field 28 includes an option type (OT) indicator which indicates the option as a home address option, an option length (OL) field indicating the length of the option field, and the HoA of the MN to which the CoA corresponds. At the access router, ingress filtering is performed using the CoA and the packet will satisfy conventional ingress filtering rules since the prefix of the CoA will be the same as that of the access router in the foreign subnet which serves as the MNs point of network attachment.
Unfortunately, the HAO presents problems in the case of multicast packets. In the multicast case, the persistent HoA cannot be used as a multicast source address because such packets will fail the multicast reverse path forwarding check that is normally performed. The MN must instead, in current systems, use its Co-located Care of Address (CCoA) on the foreign network as its source address, and a new multicast tree must be built for each new CCoA on each MN hand-off, e.g., each change in access routers used to attached to the network, to ensure that the multicast source address is topologically correct given the MN change in location. These multicast issues which can be a serious problem are discussed in detail in one or more known references relating to MIP-Multicast.
In view of the above discussion, it should be apparent that there is a need for an improved method of allowing a MN which is visiting a foreign subnet to use its HoA and a CoA (or CCoA which is a type of CoA) in a manner which will allow multi-cast reverse forwarding checks to be satisfied.
In addition to the ingress filtering problem other security issues exist with Mobile IP. Mobile IP allows for different types of headers, e.g., Hop by Hop headers and Destination Headers. IPv6 header processing rules state that the header options within an extension header (e.g., an option field) are processed by nodes according to ‘defined’ rules of that header. So Hop By Hop Header options, for example, are processed by all hops. In addition, header processing rules state that such processing nodes must process the options according to the three most significant bits of the option type, where for example, code 110 means that the packet should be dropped if the option is unrecognized and the option cannot be modified on route.
It is desirable to be able to implement nodes, e.g., routers that operate as firewalls at arbitrary or specifically selected points in a network. To be reliable from a security perspective, a router that wishes to police the contents of packets, for policy and firewall reasons, cannot expect a MN to create packets with suitable header types that will enable the enforcement point to check out all the options in a defined manner according to the existing extension header processing rules. For an arbitrary enforcement point to be fully capable of correctly checking extension header options, every packet from every node would need to carry all options within a Hop By Hop header, with the option type code at ‘111’. This would most likely result in an arbitrarily located option enforcement point discarding packets because it did not understand some options, and whose threats it cannot assess, as well as modifying options it did not like. This however is clearly not practical as it removes much of the functionality of option processing.
Accordingly, there is a need for a way to allow an arbitrary option enforcement point to examine packet options both by ignoring extension header processing rules that would normally prevent it from examining all options, as well as allowing it to ignore the option type code.
As can be appreciated from the above discussion, there is a need for improved IP addressing techniques and options which can be used to address one or more of the various filtering problems discussed above including, e.g., ingress filtering when operating from a foreign subnet, reverse path checks in the case of multi-cast packets, and the checking of options by firewalls located at arbitrary points in a network.